1. Field of the Invention
The present invention relates in general to the field of information handling systems and more specifically, to systems management.
2. Description of the Related Art
As the value and use of information continues to increase, individuals and businesses seek additional ways to process and store information. One option available to users is information handling systems. An information handling system generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes thereby allowing users to take advantage of the value of the information. Because technology and information handling needs and requirements vary between different users or applications, information handling systems may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in information handling systems allow for information handling systems to be general or configured for a specific user or specific use such as financial transaction processing, airline reservations, enterprise data storage, or global communications. In addition, information handling systems may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems.
Information handling systems continue to grow in power, capabilities and variety, and with the advent of the Internet, they have also become more numerous and more distributed. As a result, their management has become increasingly complex, in part due to the growing heterogeneity of the elements that comprise them and the diversity of their associated management environments. In response, the Distributed Management Task Force (DMTF) has developed frameworks that facilitate the interoperable exchange of management information between managed elements and corresponding management systems. One of these frameworks is the Common Information Model (CIM), which provides a consistent definition and structure of management information through the use of object-oriented techniques. As a conceptual information model, the CIM is structured such that managed environments can be viewed as collections of interrelated systems, each of which is comprised of a number of discrete elements.
The CIM, comprised of a specification and a schema, allows management-related information about these elements to be transparently exchanged between management systems. The specification describes an object-oriented meta model based on the Unified Modeling Language (UML) and defines how the CIM can be integrated with other management models. These include, but are not limited to, Simple Network Management Protocol (SNMP) Management Information Base (MIB) or DMTF Management Information Format (MIF). The CIM schema currently defines thousands of classes with properties, methods and associations that represent component elements such as, but not limited to, processors, firmware, sensors and fans, as a common set of managed objects. The CIM schema also allows for the definition of namespaces, a directory-like structure that allows classes to be organized in a more hierarchical structure. Classes within these namespaces are served by data providers, which communicate with managed objects to access data and event notifications. These providers typically implement profiles that define the CIM model and associated behavior for a management domain comprising one or more namespaces within a CIM Object Manager (CIMOM). While this architecture facilitates the tracking and depiction of interdependencies and associations between managed objects, multi-provider implementations pose challenges for CIM management clients that consume interrelated data from multiple namespaces.
For example, a CIM client is currently required to traverse though all registered profiles to determine which profiles have been implemented in each namespace and then enumerate and keep track of their associations. In addition, the client also needs to determine which central CIM class instances are associated with each of the profiles in each namespace, and then integrate all associated namespace data into a consolidated data structure representing the managed system. This approach can result in inconsistencies in data populated across different CIM-based client management applications, leading to interoperability, data integrity and manageability issues. The situation is further complicated when an overlap of CIM data exists in different namespaces. As an example, suppose provider ‘A’ implements classes 1′, ‘2’ and ‘3’ in namespace ‘A’. Provider ‘B’ implements classes ‘3’, ‘4’ and ‘5’ in namespace ‘B’. Requests for instances of classes ‘1’ and ‘2’ are routed to namespace ‘A’ and are returned by provider ‘A’. Likewise, requests for instances of classes ‘4’ and ‘5’ are routed to namespace ‘B’ and returned by provider ‘B’. However, returned instances of requests for class ‘3’ may contain duplicates as it exists in both namespace ‘A’ and ‘B’. Current approaches to this issue include the implementation of centralized CIM object repositories. Other approaches provide uniformly rendered results regardless of the source of the information, but require the CIM client to have foreknowledge of the namespace in which the information resides. Furthermore, none of these address multi-provider CIMOM implementations that comprise multiple namespaces, nor do they address the issue of CIM clients consuming interrelated CIM data from such a CIMOM. In view of the foregoing, there is a need for identifying duplicate class instances when they exist in two or more namespaces and based on predetermined criteria, selecting only the unique set of class instances to be returned.